Telegram Group & Telegram Channel
🧠 Задача для .NET разработчиков: «Загадочная утечка памяти в ASP.NET Core приложении»

🧩 Уровень: Senior .NET / Backend Engineer
🎯 Цель: Найти и устранить причину роста памяти без падений и исключений

📍 Ситуация:

У вас — высоконагруженное API на ASP.NET Core (.NET 8), работающее под Linux в контейнере.
Сервис обрабатывает тысячи запросов в минуту. Мониторинг показывает:

- Память растёт стабильно, но не освобождается
- GC работает, но не очищает выделенную память
- dotnet-counters показывает рост в LOH (Large Object Heap)
- Приложение не падает, но хост начинает свапать и тормозить
- При перезапуске — память очищается, но через 2–3 часа снова заполняется

В логах — тишина, ошибок нет. Библиотеки: Newtonsoft.Json, HttpClient, MemoryCache, EF Core.

---

🧩 Твоя задача:

1. Почему .NET GC может не освобождать LOH, даже при работе GC?
2. Какие действия вызывают накопление в LOH?
3. Как можно отследить, какие объекты скапливаются в памяти?
4. Чем опасен повторный вызов HttpClient или StringBuilder без очистки?
5. Как корректно использовать MemoryCache, чтобы избежать утечек?


💡 Подсказка:

- LOH начинается с объектов > 85,000 байт
- Часто виноваты: большие строки, сериализация, `ToString()`,
🧠 Задача для .N🧠 Задача🧠 Задача
-
Задача для .NETможет хранить сильные ссылки бесконечно, если не задано время жизни
- Частое создание

🧩 Уровень: S— может удерживать сокеты в TIME_WAIT и загонять GC в ступор


🛠 Решение:

1. Запускаем профилировщик:

dotnet-gcdump collect -p <PID>
dotnet-gcdump analyze dump.gcdump


2. Смотрим типы с самым большим retained size: List<string>, byte[], MemoryStream
→ В коде — сериализация в JSON огромных объектов без ограничения глубины

3. Находим участок с JsonConvert.SerializeObject(hugeObject) без MaxDepth

4. Исправления:
- Добавить настройки сериализации:

new JsonSerializerSettings { MaxDepth = 5, ReferenceLoopHandling = Ignore }

- Ограничить MemoryCache по размеру:

new MemoryCache(new MemoryCacheOptions { SizeLimit = 100_000_000 });

- Использовать HttpClientFactory вместо new HttpClient() на каждый запрос

5. Альтернатива: перейти на System.Text.Json с Utf8JsonWriter — меньше аллокаций

📌 Вывод:
Даже без явных ошибок .NET-приложение может стабильно "утекать" в LOH — через сериализацию, кэш или неправильную работу с потоками. Только анализ дампа памяти и правильная конфигурация GC и кешей помогут найти такие проблемы.

@csharp_1001_notes



tg-me.com/csharp_1001_notes/694
Create:
Last Update:

🧠 Задача для .NET разработчиков: «Загадочная утечка памяти в ASP.NET Core приложении»

🧩 Уровень: Senior .NET / Backend Engineer
🎯 Цель: Найти и устранить причину роста памяти без падений и исключений

📍 Ситуация:

У вас — высоконагруженное API на ASP.NET Core (.NET 8), работающее под Linux в контейнере.
Сервис обрабатывает тысячи запросов в минуту. Мониторинг показывает:

- Память растёт стабильно, но не освобождается
- GC работает, но не очищает выделенную память
- dotnet-counters показывает рост в LOH (Large Object Heap)
- Приложение не падает, но хост начинает свапать и тормозить
- При перезапуске — память очищается, но через 2–3 часа снова заполняется

В логах — тишина, ошибок нет. Библиотеки: Newtonsoft.Json, HttpClient, MemoryCache, EF Core.

---

🧩 Твоя задача:

1. Почему .NET GC может не освобождать LOH, даже при работе GC?
2. Какие действия вызывают накопление в LOH?
3. Как можно отследить, какие объекты скапливаются в памяти?
4. Чем опасен повторный вызов HttpClient или StringBuilder без очистки?
5. Как корректно использовать MemoryCache, чтобы избежать утечек?


💡 Подсказка:

- LOH начинается с объектов > 85,000 байт
- Часто виноваты: большие строки, сериализация, `ToString()`,
🧠 Задача для .N🧠 Задача🧠 Задача
-
Задача для .NETможет хранить сильные ссылки бесконечно, если не задано время жизни
- Частое создание

🧩 Уровень: S— может удерживать сокеты в TIME_WAIT и загонять GC в ступор


🛠 Решение:

1. Запускаем профилировщик:


dotnet-gcdump collect -p <PID>
dotnet-gcdump analyze dump.gcdump


2. Смотрим типы с самым большим retained size: List<string>, byte[], MemoryStream
→ В коде — сериализация в JSON огромных объектов без ограничения глубины

3. Находим участок с JsonConvert.SerializeObject(hugeObject) без MaxDepth

4. Исправления:
- Добавить настройки сериализации:

new JsonSerializerSettings { MaxDepth = 5, ReferenceLoopHandling = Ignore }

- Ограничить MemoryCache по размеру:

new MemoryCache(new MemoryCacheOptions { SizeLimit = 100_000_000 });

- Использовать HttpClientFactory вместо new HttpClient() на каждый запрос

5. Альтернатива: перейти на System.Text.Json с Utf8JsonWriter — меньше аллокаций

📌 Вывод:
Даже без явных ошибок .NET-приложение может стабильно "утекать" в LOH — через сериализацию, кэш или неправильную работу с потоками. Только анализ дампа памяти и правильная конфигурация GC и кешей помогут найти такие проблемы.

@csharp_1001_notes

BY C# 1001 notes


Warning: Undefined variable $i in /var/www/tg-me/post.php on line 283

Share with your friend now:
tg-me.com/csharp_1001_notes/694

View MORE
Open in Telegram


C 1001 notes Telegram | DID YOU KNOW?

Date: |

Start with a fresh view of investing strategy. The combination of risks and fads this quarter looks to be topping. That means the future is ready to move in.Likely, there will not be a wholesale shift. Company actions will aim to benefit from economic growth, inflationary pressures and a return of market-determined interest rates. In turn, all of that should drive the stock market and investment returns higher.

C 1001 notes from us


Telegram C# 1001 notes
FROM USA